1. Field of Invention
The invention relates to computer programming language design, more specifically: improvement of subroutine (function, method, constructor, lambda expression . . . ) declaration raising code readability and code editability factors.
2. Related Art
In computer programming, a parameter (formal parameter) is a special kind of variable, used in a subroutine to refer to one of the pieces of data provided as input to the subroutine. These pieces of data are arguments (actual parameters). For the most part programming languages use a positional correspondence between parameters and arguments [2].
Just as in standard mathematical usage, the argument is thus the actual input passed to a function, procedure, or routine, whereas the parameter is the variable inside the implementation of the subroutine.
Pseudo code example of method declaration containing two explicitly defined parameters is shown in FIG. 1.
Implicit parameters mean taking formal parameters declaration of the method from the method head part to the method body part, where each implicit parameter will be declared as an expression. [1, 3]
Respectively: method (subroutine) implicit parameters are declared in the method body part as expressions. In pseudo code this can be expressed as shown in FIG. 2.
When using implicit parameters, every undefined identifier used in the method body should be interpreted as implicit parameter of the method. Therefore, in the code fragment defined in FIG. 2, ‘lastName’ and ‘firstName’ are implicit parameters being method parameters by definition.
Code fragment shown in FIG. 2 is equivalent to the pseudo code fragment using explicitly defined method parameters shown in FIG. 3.
The problem is that implicit parameter order in the list of method parameters depends on the order how the parameters are used in the method body. Sometimes it is not preferred order by the programmers. To define function ‘PrintName’ using implicit parameters, special functionality, which could control order of implicit parameters in the list of method parameters, is necessary.
Implicit parameter order in the list of method parameters can be changed by using any statement, for example, method ‘DoNothingWith’, which accepts parameter but does not lead to any action as shown in FIG. 4.
This way it is possible to make method ‘PrintName’ to accept two parameters so, that the first is ‘firstName’ and the second—‘lastName’ and the printing algorithm remains unchanged. However, the problem is that the method ‘DoNothingWith’ is useless from a business logic perspective and in optimization phase (performed by compiler) it should be removed from the program. More practical approach would be to create special parameter order correction operator ‘#’ which would act like method ‘DoNothingWith’. The operator ‘#’ allows placing implicit parameters into the list of method (where the operator ‘#’ is used in the body) parameters without adding extra functional program logic to the abstract syntax tree. The main benefit of the operator ‘#’ is that it can be a standardized, predefined way to define parameters in one order and process them in different order without adding extra program logic information to the abstract syntax tree. This way it is possible to process operator ‘#’ in parsing phase by reducing the need for it to be optimized in the optimization phase [1, 3].
Operator ‘#’ is used as a statement in the following syntactic form:
#listOfParameters;
Where ‘listOfParameters’ is non-empty list containing implicit parameters separated by comma. Method ‘PrintName’ can be improved by using operator ‘#’ as shown in FIG. 5.
So far everything is fine, except the fact that the syntax starts to look similar as it was at the beginning, when explicit parameters were used—method declaration starts with listing of method parameters to be put into the list of method parameters.